I'm not quite sure about this one? We do build Debian with a Fedora tools tree in CI, e.g. here, and they succeed. Instead of the Debian keyring we use the distribution-gpg-keys package. What am I missing here?

@behrmann the tools tree is only used in addition to what the host OS already provides.

When I run a Debian build on my Fedora 44 machine without this, it complains first about the missing keyring and then about missing apt. It works when I run these in a Debian environment (toolbox), as then the system has these two installed. These are both available in the ubuntu-24.04 GitHub runner obviously.

@behrmann mkosi's CI is "cheating" in some way, in its Dependencies: step. I'd rather move these out of the workflow into our box config, so that they "just work". These really aren't strict test dependencies, but are necessary for what mkosi actually does. (And even if they would be pure test deps, it's still better to make them reproducible locally).

I.e. while I still believe the current change is helpful, I can rework it to be more comprehensible and entirely drop that "Dependencies:" step from the workflow. WDYT?

Note to self: I want to do this more comprehensively. I don't like #4343, it makes things even less predicable. I'd like to remove that entire "Dependencies:" step in the action, these should all move into box. mkosi should work outside of GH actions, too, these really aren't test dependencies.

One thing I'm not 100% certain about: Can we conditionally add dependencies to mkosi.tools/ image depending on the target release? If so, we can conditionally install apt-utils, pacman and the like, instead of always installing all OS bootstrapping tools. If it's not possible, then we are not worse off, as we already install all these package managers statically right now.

@martinpitt The github action isn't about the tools image. It's about installing package managers so we can build the tools image in the first place. We need to bootstrap from something. And we can't move this logic into mkosi itself as installing package managers in the system requires root privilege and is not something we want to do automatically. It's up to users to make sure we have a package manager available from which we can bootstrap.

Of course the package managers should also be installed in the tools tree, but that doesn't mean we shouldn't install them in the github action anymore.

@daandemeyer I was more thinking along the lines of "the distro of the tools tree is somewhat of an implementation detail", and "the tools tree should be able to bootstrap any distro". That's was the original motivation for this PR, to fix building a Debian ParticleOS on Fedora based machine. I can still reproduce this, I updated the description with the details.

I realize in its current form it's a bit asymmetric and inelegant (see my comment above), so I made it draft.

But of course my "drop Dependencies: step" comment was absolute nonsense, sorry about that. The tools tree needs to bootstrap from that, and if you want that to be arch then you need to install pacman. I'm not sure this should be part of the workflow that gets "exported" to users, but that's your prerogative and I'll shut up about it 😉